\chapter{Conclusions}\label{cha:outlook}
\section{Summary}
We presented our peer-to-peer approach for Wi-Fi sharing with HIP as
building block.

To achieve this, we designed an authentication procedure which is
integrated in the HIP Base Exchange. The authentication of the home router
is based on certificate which is issued by the CA of the community. The
mobile client is in possession of the token which the home router gives it 
exclusively.
The middlebox takes part in the authentication
process, verifies the certificate, and adds nonce for each peer to make
impersonation impossible. The authentication process in a peer-to-peer
manner is extremely scalable compared to the centralized way using RADIUS
server. Network failure or DoS-attacks will only affect part of the system.
The strong user authentication provides better security against attacks like
man-in-the-middle attacks.

The requirement of confidentiality is delegated to HIP so
that the transmission is protected by IPsec.   
A HIP tunnel to the home
router is used for nomadic users for the Internet access or if the direct
Internet access is granted, the hash value of the user's activity is
logged. In this way, the legal issue regarding to the Wi-Fi liability is
solved and quality of service is guaranteed. With our
proposal, a mixed business model can be possible which not only encourage
private users to share their bandwidth, but also commercial
provider have the chance to expand their wireless network, and even more:
the private and the commercial networks can complement each other.

We have implemented a prototype of our proposal. The implementation and
evaluation showed
that our approach is a  
distributed, efficient and secure architecture for Wi-Fi sharing. 
\section{Future Work and Outlook}
\subsection{Future Work}
This section outlines possible work to continue and to improve our approach.
First of all, our implementation is only a prototype and at a very
experimental level. 
Hence the first things need to be done are the code
maintenance. In addition, the following areas could be
interesting research areas to support our work.
\subsubsection{Mobility}\label{sec:mobility_problem}
Mobility is an attractive feature for Wi-Fi deployment. Especially the
seamless handover on the transport layer provided by HIP can not only be
used by Wi-Fi, but also other radio-based technologies like WiMax. 

Besides the problems of he tunneling mobility which we mentioned in section
\ref{sec:imp_state}, another challenging area for mobility is the handover
time.
In our prototype implementation, we use scripts to manually switch
from one access point to another. In the practice, this is a more
complicated problem.  
\subsubsection{NATted networks}
Our design and implementation are based on the assumption that the home
router has a publicly available IPv4 address. This may not all be the case
in some circumstances. Using rendezvous server may also
makes HIP association with Responder behind a NAT possible. This could be
another working field for our approach.
\subsubsection{Other Platforms}
Our implementation is based on HIP for Linux. For massive deployment,
implementation for other platforms, especially for Windows and Mac OS is
needed. Furthermore, other mobile platforms like PDA, smart phones can also
be working platforms.

\subsubsection{Optimization and legal issues}
We proposed a concept for optimization with hashed logging. Technically
there is no problem for this proposal, but we are not sure about the legal
acceptance of this logging activities, especially the laws of different
countries or even in different states of the USA are have different
regulation about data privacy.

Generally there is a need to make a convey about the Wi-Fi
liability in different countries. This work may not be directly connected
with computer science but it gives us guideline for our design and
implementation.
\subsection{Outlook}
As described in the thesis, the liability problem of the current Wi-Fi
sharing problem is due to the deployment of NAT and the role of the IP
address as identifier. The problem which makes the HIP deployment and
mobility difficult is also NAT, especially for the situation where the
Responder is located behind a NAT. In the following, we want to visualize the
vision of Wi-Fi sharing in the future where IPv6 and HIP is used
and no NAT is
necessary.

We assume that in the future HIP is also the running at server side like 
web servers. Members of the Wi-Fi sharing community can  share part of
this bandwidth to other people without worrying about the legal liability. A
mobile user gets connected with an external access point and gets a global
routable IPv6 address assigned. The mobile user establishes a HIP association with the
web server before for example a TCP connection is established. The web
server only sees the HIT of mobile client, and if logging is necessary, only the
HIT is logged. The IPv6 address which the access point assigned to the
mobile user is only for routing purpose and has nothing to do with the
identity. In this way, the Internet traffic is directly forwarded and no tunneling to
the home router is necessary, so that low latency is guaranteed. Mobility
under IPv6 is supported well by HIP so that application like VoIP will work
just like GSM or UMTS with smoothly handover in area with Wi-Fi signal
coverage \footnote{Provided the handover process can be achieved in an
acceptable time.}.
\nocite{tb}
\nocite{kw}

